How would you guys recommend authoring the resolveExternalModule function.

I've added a commit which gets the tests passing to demonstrate the issue : a781916

Thanks for the PR @basarat - I got the chance to discuss it a bit with @vladima and apparently there are some subtleties on our end, some of which pertain to language service scenarios. Vlad has some existing work on this, and may be able to explain a bit more.

apparently there are some subtleties on our end, some of which pertain to language service scenarios

If it is because the language service didn't get such a resolved file as a part of its original file set : then this can be solved by lazily expanding the file set : https://github.com/TypeStrong/atom-typescript/blob/8df1482222fb88363b504d9c27f98692e938e44f/lib/main/lang/core/languageServiceHost2.ts#L353-L358 I've tried the code in this PR with atom-typescript and it works like a charm 🌹

I guess main points of inconvenience on our end are:

1. when language service is hosted inside the VS you in general don't have access to all sys functionality meaning that operations like isDirectoryExists, isFileExists and readFile should be delegated to the host.
2. the way how VS side works today is slightly different from the model used by tsserver. Main difference is that currently VS pre-resolves all tripleslash-refs/imported files before creating script language service so if resolution process will be just changed on the script side - this will break VS integration.
3. per External module resolution logic #2338 we would like to have ability to switch module resolution from node style (with folder walks) to requirejs (that will use baseURL) and vice versa. Ideally module resolver should just a function (moduleName: string, containingFile: string, compilerHost: CompilerHost) => string so if somebody needs more involved method to resolve modules - he can do this by just replacing this one part. It does not directly contradict with proposed solution - it just needs to be slightly reshaped.

I guess main points of inconvenience

@vladima Taking your points into consideration I guess you are recommending:

• adding readFile and fileExists to host ... and then using sys inside host.
• after that refactoring use the resolver function to be (moduleName: string, containingFile: string, compilerHost: CompilerHost) => string and use host.readFile/host.fileExists inside.

So:

• ^ Is the refactoring I am suggestion correct?
• What is shim host? < you might same me some time digging through the code :)

What is shim host?

do you mean this guy ? The idea behind it (and shims in general) is that they act as a send\receive proxies whose purpose is to extract incoming parameters from JSON, call corresponding method on the language service instance, wrap its return value to JSON and send it back.

Is the refactoring I am suggestion correct?

In general yes, you got the idea. I need to think more about details of interaction with VS that should be handled.

do you mean

Yup. Thanks. I'll see if it comes up in this refactoring (I am sure it will) :)

In general yes, you got the idea

I'll give it a go 🌹

Investigating a better method

Pushed basarat@a17c6aa

The current changeset is ready for an early review if anyone is interested. I'm moving on to adding tests for this.

Tests pushed. The PR is ready for review 👍 🌹

TSC may not be able to output a d.ts to a separate location, but a post-compile build step easily could. It seems to be fairly common for typings to sit in a typings directory.

That being said, I believe there is value in setting a standard for how people should distribute their TS/JS packages (no typings folder) and expand it later if necessary.

believe there is value in setting a standard for how people should distribute their TS/JS packages (no typings folder) and expand it later if necessary.

Thanks ❤️

Also at the moment the typings from the typings property are currently of the form declare module "foo/bar" and those typings are not the target of this PR anyways 🌹

👍 on this functionality!

I've pulled with PR into the moduleResolution branch in this repo - this will cover node related part of #2338 and the rest of the work on this proposal will be continued in that branch.

Thanks!

Thanks @vladima!

This should be in the 1.6 release